查看原文
其他

金融企业应用对象存储的架构设计方案 | 周末送资料

twt社区 twt企业IT社区 2022-07-03
【摘要】本文总结了金融企业在应用对象存储前应考虑的关键点、选型评估的方法,重点介绍了对象存储方案如何进行架构设计。

【作者】guanziliu


背景

企业不断前进发展内在需求,促使企业管理不断主动变革,应对挑战。同时,随着企业的发展,不断产生的非结构化数据(非结构化数据,包含对象存储和文件存储)规模也越来越庞大。降低成本和提升效率的KPI需求,促使管理层不断寻找新的解决方案,创造新的价值,应对新的挑战。

某企业从2013年开始追踪研究对象存储解决方案,对比了E厂商H厂商 D厂商等解决方案,同时也开展了基于OpenStack框架下的Swift对象存储研究,技术选型方案汇报到管理层后,从技术先进性,企业发展战略,社区热度,稳定性,成本,发展路线图等方面综合考量,评估,做出了使用Ceph作为对象存储开发技术原型的决定。

第二年底自研对象存储正式上线,对象存储在该企业的应用规模得到快速发展,如今已经达到了数十PB的规模,分布在数个不同地域的数据中心。在自己研发的对象存储占据主导地位同时,还有H厂商和I厂商的对象存储应用在不同场景中,其中I厂商的容量快速扩张,D厂商的对象存储在竞争中败下阵来,逐渐被淘汰。


对象存储发展的方案建议

企业发展的不同阶段,不同的战略目标,面临的IT管理的不同挑战,决定企业会选择哪种存储发展路线图,决定企业是否使用对象存储,如何使用对象存储。这是一个因地制宜的决策过程。很难有一个统一的对象存储发展方案来满足所有的企业。

但是有如下的因素,在所有的对象存储方案中都应该考虑的:

1. 准确的需求分析

需求分析是最重要的基础,如果没有需求分析,成本和收益分析就变成了无本之木,无源之水,后续的方案设计就变成了空中楼阁。

2. 企业发展战略和目标,IT管理战略和目标

技术发展路线和方案,永远要服务于IT管理目标,服务于企业战略发展。这样才能取得多赢。

3. 对象存储的成本和可用性之间,评估并设置一个恰当的平衡点

不谈成本和收益的架构设计没有实际的意义。过高的可用性浪费了企业成本,过低的可用性却不能满足业务的需求。这个平衡点很难把握。


对象存储的选型评估

当前对象存储主要应用在: 大数据分析、备份、归档、内容分发、云存储5个场景中。

针对具体的对象存储应用场景,可以针对如下的指标设置不同的打分权重,比如用在公有云场景中,租户管理能力就是一个加大权重的考核点。在高可用方面,是否支持跨地域数据中心部署存储集群是一个重要的考核点。



当前市场上有很多对象存储解决方案,挑一些具有代表性的产品来看,其中 I厂商的对象存储,在跨数据中心部署存储集群方面的能力比较突出,纠删码的配置也比较灵活。同时支持软件部署和软硬一体部署两种方式。H厂商,支持元数据检索功能。另外具备压缩去重功能。还在删除数据的时候具备数据粉碎功能,增强了安全级别。只支持软硬一体的部署方式。N厂商,支持跨数据中心部署全局纠删,支持元数据检索。存储空间使用效率稍低。

Ceph对象存储,是社区很热的开源项目,也具有很大的吸引力。面对单一的具体的需求场景,就需要对比更具体的技术细节,如面对备份场景,bucket的创建数量,是否支持版本,支持版本数量有无限制?读写吞吐多大?而面对多应用需求场景下,各种具体的技术细节都要考虑到,比如公有云场景:还有着重考虑多租户管理的能力。


文件存储和对象存储的差异

非结构化数据,包含对象存储和文件存储,那么在不同的场景中如何选择用对象存储还是文件存储呢?从技术角度,我们要从这两种存储的本质来看,对象存储访问接口基于http协议,这种协议显然比NFS和CIFS协议更适用于互联网。整个互联网就是以http协议作为基石的。因此对于互联网类开发应用,如IOS安卓APP之类的手机应用,直接调用基于http的接口显然更方便。如果使用NAS存储,还需要应用程序将文件存储封装成http接口的API提供给其他程序模块调用。


应用由文件存储转对象存储的理由

在使用对象存储之前,企业的非结构化数据都是存放在NAS存储设备上,主要以NFS和CIFS的方式对用户提供服务。

在使用文件存储的过程中,开发同事眼中的NAS有如下的问题:

1.要走两天以上的流程才能申请一个NAS卷挂载到指定的服务器上

2.一个NAS卷上读写过于密集会不会有性能问题呢?每次查询都要读取一个XML文件,而且要频繁更新

3.我们的软件系统是按照业务系列分套隔离的,NAS设备要不要分成多套进行物理隔离

4.基于NAS存储设备的高可用架构设计复杂,具体某场景架构描述如下

1). 主备NAS卷来解决数据丢失问题。

2). 主备分别使用不通硬件厂商设备、并部署在不通的机房来隔离硬件影响。

3). 应用分成4套来隔离业务影响,存储也分成4套保证能真正的完全隔离。

4). 实时灾备到张江,保证能够应对灾难。

5). 多网络区域 多应用实例的复杂设计

基于上面的问题,开发同事期望存储设备能够满足如下的要求:

1.应用开发不需要考虑存储的架构设计;

2.应用开发不需要考虑存储的容量管理;

3.存储设备过保替换对应用和影响降低到最小;

4.存储容量可以弹性,支持高吞吐,高可用且稳定,数据安全,简单易用;不会随着容量的成倍增长,而引发存储运维成本的成倍增长;

5.专注应用开发运维本身,无需考虑存储;

6.简化存储的运维管理工作,降低运维管理成本。

基于上面的理由,开发同事做出了由对象存储替换文件存储的应用架构调整决定。

以客观的技术视角来看,两天时间申请一个NAS卷,是因为IT管理和人力投入综合决定的,如果用自动化来处理只需要30秒钟。NAS卷的响应时间是对象存储的10分之一,在应对随机IO的场景中比对象存储更出色。至于存储容量的弹性管理,随时能扩容的前提是存储资源池中提前储备了物理资源。一定程度上增加了成本。

存储设备用满5年,需要替换为新的NAS存储设备,在不同品牌NAS存储设备之间数据迁移完成后,应用需要读取新存储设备上面的nas卷,则必须在操作系统上停止进程对NAS卷的访问,才能umount旧的NAS卷,mount新存储上的NAS卷程。这个新旧NAS卷切换的过程中,尚不能完全的做到在线的切换,因此需要申请一个变更时间窗口,而对运营 开发 业务沟通和申请变更窗口成为一个比较花时间的工作。对象存储的分布式架构,可以在线完成设备过保替换。

再举一个场景应用的例子

保险行业有一个比较特殊的应用场景,电话录音,每一个通过电话销售出的保险都需要录音存档,按照法规监管的需求保留一定的年限。原来这些数据都是长期保留到磁带上。随着监管抽检录音时效的要求,受限于磁带从介质保管室放入磁带库需要人工操作,短时间内恢复数百通不连续录音的时效不能满足监管的需求。如果这些数据不放置在离线磁带上,而是放置在对象存储上面,对录音的查询和调阅时效,会提升很多!


大型金融集团对象存储架构设计

系统重要性定义

在金融行业中,针对具体的场景分析,我们可以按照如下的几个点,来划分系统的重要性,区分不同的场景和保障等级。针对A类系统,我们可以提出更高的可用性需求;针对C类系统,我们可以降低可用性需求从而降低成本。

对象存储架构发展路线图规划与制定:

要制定自己的对象存储发展路线图,包括自研对象存储,开源对象存储产品应用与外购商品化对象存储三种技术路线,三种技术路线又可以以不同的比例组合起来。

在制定对象存储发展路线图的过程中,不同的企业面对的具体挑战不同,制定的路线图也会有差异。但是我觉得如下的考量因素是共用的。

1. 是否必须对象存储才能满足需求,是否有替代方案;

2. 成本因素在决策中占多大的比重;

3. 技术先进性在决策中占多大的比重;

4. 企业战略发展目标在决策中占多大的比重;

5. 组织管理目标在决策中占多大的比重;

机房规划设计

1.要根据业务的重要程度决定对象存储的服务承诺,对象存储服务的承诺,一定程度上依赖机房的高可用,所以要根据成本和需求等因素综合考量选择不同级别的机房;

2. 要考虑主要客户群所处的地理位置。如果主要客户在东部沿海,那么在上海选用一个数据中心会提供更快的响应速度。

网络规划设计

对于对象存储使用的网络,分成三个基本的网络区域,管理网络,用于对象存储设备的底层管理,主要考虑物理隔离。内部数据传输网络,用户存储节点之间用来交互数据,要求具备充分的带宽。对互联网提供服务网络,这个网段用来响应互联网http请求。

服务器规划设计

如果是基于X86架构的服务器构建ceph对象存储,需要考虑CPU数量和频率 内存的数量和频率,以及硬盘的数量,容量,和类型。如下是一种实际应用的典型配置:

Intel Xeon E5-2630(v3) 2.40GHz 2CPU 16core 88G(DDR4-2133)内存
2400G(SSD,S3710,6Gb,SATA2.5)+124TB(SATA 3.5,7.2K)
2Intel万兆双口网卡(X540芯片,电口)

其中的硬盘的数量和大小就是充分考虑了,节点故障和硬盘故障的恢复时效。

负载均衡的规划设计

DNS 域名解析,可以解析到不同的IP地址上,采用DNS轮训的策略,一定程度上能够实现负载均衡,但是DNS不具备故障探测的功能,当一个IP故障的时候,DNS仍旧会分发请求,造成对象存储的访问请求失败。

DNS+F5的方式,可以比较完美的解决负载均衡的问题。但是F5作为世界知名负载均衡厂商,成本是企业需要考虑的一个点。

DNS+LVS 可以一定程度上实现负载均衡,同时解决了DNS不具备故障检测的功能。在转发模式一般选择性能最高的DR模式,要注意的是LVS DR模式不能跨网段。

DNS+LVS+keepalived 方案,用来规避LVS发生故障的缺陷,实现LVS的高可用。

DNS+ LVS+keepalived+nginx 方案用, nginx用来做分流-一种负载均衡的另一个名字,主要可以根据IP URL权重 响应时间四个维度来设置参数进行负载均衡。

我们还可以用cdn进行内容加速,因此最终采用的对象存储架构为CDN+DNS+ keepalived+LVS+nginx+对象存储。

架构设计的通用考虑规则:

1、对象存储系统的每个逻辑实体必须要要有冗余,且要支持横向性能扩展,并对客户端透明,规避单点风险;

2、对使用对象存储的生产应用运行状态进行监控,监控方法应尽量仿真用户的实际使用方式;

3、当对象存储系统的某个部分发生异常的时候,能快速隔离或通过重启来恢复功能模块的正常使用;

4、企业内网与外部互联网对对象存储的访问,应该做好数据隔离和权限隔离。对于互联网上传数据,企业内网下载的场景,应该做好防病毒扫描。对于企业内网上传数据,互联网下载数据的场景,应该通过权限控制或者API控制的方式严格阻止。对于不同应用之间共享对象存储数据的场景,可以选择全量授权和bucket授权两种方式;

5、针对不同的网络安全区域,提供不同的对象存储接口以实现对应的权限控制;

6、是否有数据加密的需求;

7、是否有容灾和计费的需求;

8、并发、吞吐量、可用率等方面的需求;

架构设计中的两个小例子

1、Ceph存储中 client 跟 OSD的 TCP交互很多,如果没有提前放大TCP端口范文,会导致TCP连接端口耗尽造成故障

2、Ceph存储中,应该将OS的 openfile参数调整为最大,否则会导致OSD进程down。

POC测试的部分结果与数据

从下面部分的测试结果来看,在网络带宽受限的条件下,对象存储的写响应时间在100ms 左右,读响应时间也在20ms左右。

点击“阅读原文”可下载原文档

觉得本文有用,请转发或点击“在看”,让更多同行看到


 资料/文章推荐:

欢迎关注社区 "对象存储"技术主题 ,将会不断更新优质资料、文章、问答。地址:

https://www.talkwithtrend.com/Topic/24493

下载 twt 社区客户端 APP


长按识别二维码即可下载

或到应用商店搜索“twt”


长按二维码关注公众号

*本公众号所发布内容仅代表作者观点,不代表社区立场

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存